http://localhost:7080/coregui/
This is the RHQ 4.1 beta release. It was released on August 11th, 2011
The autodiscovery portlet is by default disabled on the dashboard. Go to the Inventory to see the discovery queue.
Webkit based browsers will not automatically forward you from the installer to the login page. Manually switch to
http://localhost:7080/coregui/
RHQ 4.1 requires Java 6 – it may work on Java7, but has not yet been extensively tested (feedback is welcome).
Firefox 5 is not yet supported, as the version of (Smart)GWT used in RHQ does not support it.
Chinese and Portuguese translations are unfortunately missing from this build. They will be in the final 4.1 release.
Drift Management is a new feature and not ready for anything other than preview and feedback. DO NOT RELY ON THIS FEATURE! Any part of it may change in the future, be incomplete, or be buggy. Nevertheless we are looking for feedback (not bug reports) so feel free to play and let us know what you think.
Notes/Tips:
Delete of drift objects probably will not work.
The include/exclude Filters ARE NOT YET IMPLEMENTED! So, be careful when testing drift detection of JBossAS files using the 'Core Files' drift configuration template. It will start monitoring all of the potentially thousands of files under the JBossAS root dir. You are encouraged to test drift using a platform resource. Use the 'File System' drift configuration template available on any platform resource and set the base directory to a specific directory you want to monitor.
Server Configuration Synchronization is provided as a teaser by which we'd like to gather your input so that we can make it more useful and robust. Like drift management do not rely on this feature.
Japanese translation of the UI done by Fusayuki Minamoto
Chinese installer messages by Jijun Liu
Dependent values: properties in the UI can now be dynamically filled by e.g. selecting other resources. This is first used in the AS7 plugin. See Needed - dependent properties and linking
The below two release note items were as a result of BZ 644328
In past versions, RHQ supported deploying bundles to any group, so long as that group had only platforms as its members. So long as the member resources were of the category PLATFORM, it did not care what resource types those members were (i.e. you could have had a mixed group of Linux, Windows and Solaris platforms, for example).
However, now RHQ supports bundle deployments to non-platforms and as such as changed the way it implements this feature. Because RHQ can now support deploying to any type of resource (but only if those resource types can support bundle deployments), RHQ can no longer support deploying to mixed groups, since mixed groups do not have a single, associated resource type (they can have members of many kinds of resource types - and each kind of platform, Linux or Windows or Solaris for example, are considered different resource types).
Therefore, any previous Bundle Destinations that have been created with a mixed group can no longer be used. You must create a new set of compatible groups and assign them to their own new bundle destination. If you need to deploy to heterogeneous group of platforms, split your mixed group into separate compatible groups. For example, if you had a bundle destination that was assigned a mixed group consisting of 3 Linux platforms and 2 windows platforms, you must now create two compatible groups (one containing the 3 Linux platforms and the other containing the 2 windows platforms) and then create two new destinations for your bundle - one destination assigned the Linux compatible group and one destination assigned the Windows compatible group. Now you can deploy your bundle to the two sets of machines, albeit in two deployments, rather the one.
Due to the new bundle feature allowing RHQ users to deploy bundles to non-platforms, changes needed to be made to the bundle API. If you wrote remote CLI scripts to deploy bundles, the following changes may affect you.
org.rhq.enterprise.server.bundle.BundleManagerRemote.createBundleDestination
This method adds a new "destBaseDirName" parameter. It is the name of the base directory location where the bundle will be deployed. This isn't the directory itself, it refers to the named location as defined in the agent plugin's descriptor for the resource's type.
org.rhq.enterprise.server.bundle.BundleManagerRemote.getResourceTypeBundleConfiguration
Used mainly to support user interfaces (like the RHQ GWT GUI), this provides the bundle configuration for a given compatible group (this is going to be the compatible group's resource type's bundle configuration). Use this to find out the valid values that can be passed as the above "createBundleDestination" method's "destBaseDirName" parameter.
This is a new feature that enables you to monitor resources for unplanned and/or unexpected changes that are referred to as drift. You can get background on the feature including motivating use cases and design diagrams here. Here is a brief list of things are functional:
User can schedule drift detection to occur for a resource at regularly scheduled intervals.
User can enable/disable drift detection.
User can view history of changed files.
Agent performs file system scans to track changes.
There is limited support in the CLI for:
Querying for change sets (a change set is some what analogous to a commit in version control systems)
Query for files included in change sets
Generate and compare snapshots (A snapshot is a view over time of files under drift detection.)
Here are some notable things missing and/or known not to work at this time:
Filtering is not yet fully implemented. When you create a drift configuration, you can specify filters to further refine the set of files that will be monitored. Those filters are not yet supported on the agent.
Files added in new subdirectories (created in directories already under drift detection) are ignored during the drift detection file system scans.
There are plans to support viewing and downloading files, but that functionality is not yet implemented.
There are plans to provide a diff editor for manual remediation in a future release.
There are plans to integrate with the alert system in a future release.
There are plans to expand the remote APIs for use from the CLI and other remote client.
There are plans to support golden images.
A first implementation of the synchronization of configuration between different RHQ servers. By now only a rudimentary support is provided through CLI and not many subsystems in RHQ can be synchronized. This feature is provided as a "teaser" and is a work in progress. You can read more about it here.
Brand new AS7 plugin, supports JBossAS 7.0.0 see RHQ and AS7
SNMPTrapd plugin does now support SNMP inform messages (See BZ 723800 by Elias Ross)
Brand new mod_cluster plugin (supports only JBoss 4.2) - Design - mod_cluster
User documentation on the RHQ wiki has not been updated yet - it still documents RHQ 3.0.
Some error messages will be masked and instead print "InvocationTargetException: please see server log for more details", but the server log may not necessarily provide more details.
The installer shows some non-replaced {} properties.
Some properties are editable when viewing a configuration in read-only mode.
Clicking Reset button on user or role edit view results in an error.
Some parts of the UI are still in non-GWT technologies
Metrics on the summary page of an autogroup do not work. Go to the monitor tab to view them
Metric graphs can not be added to the Monitor->Graph page
If you want to ignore resources, there is sometimes a red box saying "could not ignore.." - this is harmless. If you refresh the auto-discovery portlet, you will see that the resources are indeed ignored.
Similar to above, if you elect to import resources, and it takes longer than 10 seconds to complete the import, you will get a red error message indicating the timeout. This is usually harmless. BZ 701314
For a list of issues that still exist in the very latest RHQ 4.0 code, see Bugzilla.
The GWT part of the UI has partially been translated into German and Japanese ( Chinese and Portuguese are unfortunately missing from this build, but will be in 4.1 final). You can e.g. access the German UI
by appending
?locale=de
http://localhost:7080/coregui/?locale=de
de for German
ja for Japanese
Please ping us if you want to help translating the UI to your language.
Please report all bugs you find in Bugzilla. If you find a bug that has been recorded in the above list, please leave a comment on them especially if this needs special steps to reproduce.
You can download the release here.